Sharing DXL Script to DOORS server

So I wrote a script in dxl for DOORS and want it so that everyone has access to it. It also contains some .bmp graphic files that need to be store on the network. Is there a to upload the script to the DOORS server so that everyone who needs it has access to that script file, and a way to upload any other attachment files so the script can run properly?

Currently I've just uploaded it to a network folder in windows and people can access it from there, but is there a more formal way in DOORS to do this?
phan423 - Mon May 21 13:22:15 EDT 2012

Re: Sharing DXL Script to DOORS server
llandale - Mon May 21 13:48:29 EDT 2012

DOORS does not provide a mechanism for the server to provide DXL to the clients. Storing such DXL on some common network folder is the standard method. Problems come when not everybody can access that netork folder.

-Louie

Re: Sharing DXL Script to DOORS server
M_vdLaan - Thu May 24 04:54:02 EDT 2012

Hello phan423,

Perhaps making an obvious remark here (but perhaps not): there are multiple ways of making scripts 'available' to users via a network share.

You can make scripts available in the addins or projectaddins folder as used by DOORS. This can be used to make it available to everyone, or those who have the addins directries properly configured.

Alternatively, you can store it somewhere on the network so people (with DXL execution rights) can copy/paste it into the Edit DXL window to run it.

Which one is it you're using?

Re: Sharing DXL Script to DOORS server
SystemAdmin - Fri Jun 01 16:31:27 EDT 2012

We store all our script on a networkshare. This networkshare is referenced via the DXL Security feature of DOORS. No modification to DOORS corefiles, bugfixes to script can easily be deployed, high security because a standard user will be unable to develop his own tools that might cause damage to the DB.

In our enviroment even the DOORSHOME is moved to the networkshare. This is because of security reason. No user shall be able to introduce DXL Code to the system.

I believe this is the most formal, secure and easiest way to use scripts from a network-share.

In case a user has no access to the share the script are just missing. But in case you move the DOORSHOME to a share and the user has not access DOORS will not start.

Re: Sharing DXL Script to DOORS server
llandale - Mon Jun 04 17:44:07 EDT 2012

SystemAdmin - Fri Jun 01 16:31:27 EDT 2012
We store all our script on a networkshare. This networkshare is referenced via the DXL Security feature of DOORS. No modification to DOORS corefiles, bugfixes to script can easily be deployed, high security because a standard user will be unable to develop his own tools that might cause damage to the DB.

In our enviroment even the DOORSHOME is moved to the networkshare. This is because of security reason. No user shall be able to introduce DXL Code to the system.

I believe this is the most formal, secure and easiest way to use scripts from a network-share.

In case a user has no access to the share the script are just missing. But in case you move the DOORSHOME to a share and the user has not access DOORS will not start.

Without going into details, I think I have defeated all existing restrictions on running DXL. You can defeat curious and clusmy folks but not determined folks.

Re: Sharing DXL Script to DOORS server
kbmurphy - Mon Jun 04 22:17:16 EDT 2012

SystemAdmin - Fri Jun 01 16:31:27 EDT 2012
We store all our script on a networkshare. This networkshare is referenced via the DXL Security feature of DOORS. No modification to DOORS corefiles, bugfixes to script can easily be deployed, high security because a standard user will be unable to develop his own tools that might cause damage to the DB.

In our enviroment even the DOORSHOME is moved to the networkshare. This is because of security reason. No user shall be able to introduce DXL Code to the system.

I believe this is the most formal, secure and easiest way to use scripts from a network-share.

In case a user has no access to the share the script are just missing. But in case you move the DOORSHOME to a share and the user has not access DOORS will not start.

Maybe I'm just naive and optimistic, but I honestly feel that if the access rights on the items in a DOORS database are set up properly, there is no risk in letting users run whatever DXL they like, and jumping through hoops to "secure the database" by making it hard to run DXL is a complete waste of time, while adding other risks (like setting DOORSHOME to have files containing 9.3.0.7 but the client software starting DOORS is 9.2.0.5. I've seen it).

Re: Sharing DXL Script to DOORS server
llandale - Tue Jun 05 13:15:36 EDT 2012

kbmurphy - Mon Jun 04 22:17:16 EDT 2012
Maybe I'm just naive and optimistic, but I honestly feel that if the access rights on the items in a DOORS database are set up properly, there is no risk in letting users run whatever DXL they like, and jumping through hoops to "secure the database" by making it hard to run DXL is a complete waste of time, while adding other risks (like setting DOORSHOME to have files containing 9.3.0.7 but the client software starting DOORS is 9.2.0.5. I've seen it).

It's a lot easier to accidental damage (delete an object) or deliberate massive damage (purge all modules in a folder), or massive deliberate compromize (dumping all secret requirements) with DXL than with the GUI.

Yes, that DOORSHOME thing didn't sound right but I didn't quite understand it.

-Louie

The low point of my career was deploying a <reasonably well> tested "PurgeAll" script; purging old useless Objects. Some idiot failed to consider what happens when a module lacks a certain attribute and ended up putting all Objects in the ToBePurged skip list. Worse, some other idiot got a copy, tweaked just a couple lines, and erased all the objects in an entire Project.

Yeah, it's funny ---now---.